A rogue access point (AP) (e.g., such as the commonly known “evil twin”) can be a significant security threat for 802.11 networks and/or other like WLANs. The term evil twin generally refers to a rogue AP that appears to be a legitimate one offered on a given premises, but actually has been setup by a hacker or other unauthorized entity to intercept and/or eavesdrop on the wireless communications of clients and/or users connecting to and/or employing the AP, e.g., to surf or otherwise access the Internet.
For example, such evil twins are commonly employed in or near locations or venues that provide the general public access their WLAN, i.e., public hotspots. Generally, the public uses a laptop or other suitable portable device or client (e.g., that is Wi-Fi enabled) to access the wireless connection provided by the legitimate AP, e.g., which may be owned and/or operated by the particular location or venue. For example, hotspots are often found at restaurants, train stations, airports, libraries, hotels, hospitals, coffee shops, bookstores, fuel stations, department stores, supermarkets, schools and other public places. However, an evil twin setup in such a location seeks to trick or otherwise deceive users into connecting to the rogue AP as opposed to the legitimate AP, i.e., the AP to which the user may really desire a connection and/or the AP to which the user thinks they are really connecting. Often, the deception is perpetrated by making the otherwise rogue wireless network appear to be legitimate to the unwitting user by simply giving the rogue AP a similar name to the legitimate WLAN and/or AP being offered and/or operated on the premises. In this regard, it remains important, especially in the case of public APs, for end users to positively known the AP to which they are connecting.
As is known in the art, 802.1x (an IEEE standard for port-based network access control) combined with EAP (Extensible Authentication Protocol) provides a framework to authenticate and control traffic to a protected network. By applying different authentication protocols such as EAP-TLS (EAP-Transport Layer Security) and/or EAP-TTLS (EAP-Tunneled Transport Layer Security), clients (also known as supplicants in 802.1x parlance) and APs are able to achieve mutual authentication. In a typical deployment, an authentication server (e.g., such as a RADIUS (Remote Authentication Dial In User Service) server) is used as part of the framework.
While the foregoing approach is largely acceptable for regulating the access of WLAN clients to network resources, it generally falls short at protecting miscellaneous clients from potentially harmful wireless networks. That is to say, existing solutions are for the most part targeted to closed network environments, i.e., where both the WLAN clients and APs are managed and/or controlled by the same entity (i.e., a company or other enterprise) to provide mutual authentication. Thus, in the case of EAP-TLS for example, a public key of an AP has to be provisioned on every client machine in order for that client machine to be able to connect to the AP. Accordingly, while this can usually be done rather efficiently for each user or client machine of a given company or enterprise (i.e., seeing as the enterprise will generally have access to and/or control over the client machines), it is largely impractical for public users or visitors (i.e., where the enterprise or AP owner/operator will generally not have access to and/or control over the respective client machines of public users or visitors). Moreover, the forgoing approach still may not satisfactorily answer the question of AP ownership. For example, a visitor or other user in a particular venue may only want to connect to APs owned and/or operated by that particular venue. 802.1x does not generally provide a positive identification of the entity that owns/operates a particular AP.
Accordingly, a new and improved system and/or method is disclosed that addresses the above-referenced problems and others.